The Generalized Multiprotocol Label Switching (GMPLS) provides a control plane framework to manage arbitrary connection oriented packet or circuit switched network technologies. Two major protocol functions of GMPLS are Traffic Engineering (TE) information synchronization and connection management. The first function synchronizes the TE information databases of the node in the network and is implemented with either Open Shortest Path First Traffic Engineering (OSPF-TE) or Intermediate System to Intermediate System Traffic Engineering (ISIS-TE). The second function, managing the connection, is implemented by Resource ReSerVation Protocol Traffic Engineering (RSVP-TE).
The Resource ReSerVation Protocol (RSVP) is described in IETF RFC 2205, and its extension to support Traffic Engineering driven provisioning of tunnels (RSVP-TE) is described in IETF RFC 3209.
Relying on the TE information, the GMPLS supports hop-by-hop, ingress and centralized path computation schemes. In hop-by-hop path calculation, each node determines only the next hop, according to its best knowledge. In the case of the ingress path calculation scheme, the ingress node, that is the node that requests the connection, specifies the route as well.
Finally, in the centralized path computation scheme, a function of the node requesting a connection, referred to as a Path Computation Client (PCC) asks a special element, referred to as a Path Computation Element (PCE), to perform the path calculations, as described in IETF RFC 4655: “A Path Computation Element (PCE)-Based Architecture”. In this scheme, the communication between the Path Computation Client and the Path Computation Element can be in accordance with the Path Computation Communication Protocol (PCEP), described in IETF RFC 5440.
When a PCC starts or requires the computation of a set of paths, the PCC first selects one or more PCEs. Once the PCC has selected a PCE, it sets up a session to the PCE. Upon receiving a connection request, the PCC sends a path computation request to the PCE (PCReq message) that contains a variety of objects that specify the set of constraints and attributes for the path to be computed. Each request is uniquely identified by a request-id number (Request-ID-number) and the PCC-PCE address pair.
Upon receiving a path computation request from a PCC, the PCE computes paths for the request. If it manages to compute paths that satisfy the given constraints, the PCE sends a response to the PCC in which it enumerates the calculated path(s). If no proper paths can be found, the PCE responds to the PCC and indicates that no paths have been found for the request. In PCEP, the PCRep message implements the PCE response.
There are several circumstances in which a PCE may want to notify a PCC of a specific event. For example, suppose that the PCE suddenly gets overloaded, potentially leading to unacceptable response times. The PCE may want to notify one or more PCCs that some of their requests (listed in the notification) will not be satisfied or may experience unacceptable delays. The PCNtf message is used in these cases. The PCEP Error message (also referred to as a PCErr message) is sent to indicate protocol error situations, when a protocol error condition is met or when the request is not compliant with the PCEP specification.
The document IETF RFC 5521, “Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions” defines extensions to the PCEP for excluding particular resources from the path calculation. It allows mandatory and PCC desired exclusion of any resources, such as interfaces, nodes, and domains. For example, if the PCC knows of a resource failure, it can specify it as an Exclude Route Object (XRO), to tell the PCE to avoid it for this specific path calculation.
A working group draft suggests the extension of PCEP with synchronized path computation capability. This allows the PCC to request multiple parallel path calculation, for instance a protected path with the corresponding protecting paths. The document IETF RFC 5557, “Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions in Support of Global Concurrent Optimization”, provides global path optimization capability with concurrent path calculation requests.
Other individual and working group documents deal with developing the path computation request description with the support of detailing technology specific as well as multi-technology constraints, without making changes to the overall PCE communication scheme.
The PCE, in order to be able to provide paths, has to have a view about the network and the free resources. In GMPLS, the participating control plane nodes synchronize their network view. That is, they advertise the TE information of their local resources and collect the advertisement of other nodes. For this purpose they use a Traffic Engineering extended version of the routing protocols, such as OSPF-TE, as described in IETF RFC 3630: “Traffic Engineering (TE) extensions to OSPF version 2”, or ISIS-TE, as described in IETF RFC 3784: “Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)”.
The PCE participates in the resource advertisement procedure and thus collects the TE information, in the same way as the other nodes. The PCE may also advertise its capabilities to the PCCs using OSPF-TE, as described in IETF RFC 5088: “OSPF Protocol Extensions for Path Computation Element (PCE) Discovery”, or ISIS-TE as described in IETF RFC 5089: “IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery”.
The IETF individual draft document “draft-lee-pce-ted-alternatives-02.txt” provides an alternative method where the PCE collects the TE information directly from the nodes.
The Resource ReSerVation Protocol (RSVP) protocol described above defined a simple but effective method for any intermediate node to report flow related failures, namely the ERROR_SPEC object. This object encodes the node that reports the problem, as well as the nature of the error, with a help of a major error code and a detailing error value. As the RSVP-TE is being developed, new error codes and new values are being specified. The error code and error value pair is therefore suitable to specify the cause of the connection failure.
At the same time, the ERROR_SPEC object is not able to accurately describe which resource caused the failure, as it defines the reporting node only. The IETF RFC 3473 defines a new type of the ERROR_SPEC object that not only encodes the reporting node, but also provides a container to carry Type-Length-Values (TLVs) to identify the problematic data plane interface. The document IETF RFC 4920, “Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE” enables the use of further TLVs for describing further details of the problem. With this extension, the RSVP-TE could provide more accurate information on the location and the context of the failure to the ingress node that requested the connection.
If an LSP setup fails, the initiating node is informed through RSVP-TE error signaling mechanisms, and the initiating node can request from the PCE a new path to the same destination. This new PCReq message can contain additional information to exclude the specific error causing resource, such as the node, the interface, the Autonomous System (AS) number, the Shared Risk Link Group (SRLG) ID, the label, or the switching type, listing them as subobjects of the XRO. This could give some hints to the PCE about the location of the error, but it is not always possible to accurately pinpoint the location or the exact cause. An XRO can be added to a path request in many situations, and so the presence of an XRO does not necessarily mean that an error occurred during path setup, and so using the XRO as an error indicator is not adequate.
Furthermore, this error information providing mechanism requires a subsequent path computation request. When the connection requesting node cancels the signaling as a result of the failed setup, the PCE will not be explicitly informed on the failure or success of the connection setup.
Although the PCE may infer the success of the connection setup when it receives updates to the available network resources, this implicit method does not ensure reliable one-to-one mapping between the calculated paths and the noticed changes to the resources. Besides, the absence of resource changes does not necessarily mean that the connection setup has failed.
The shortcomings of the prior art mean that the PCE can obtain only limited or inappropriate information on the feasibility of the calculated paths. Thus, it can apply only limited policy sets impacting the performance of the network. For instance, it might infer a failure and decide to avoid a particular resource when setting up a future connection, even though the failure was a transient one. Alternatively, the PCE might have insufficient information to infer the failure of a resource, and would then take the failed resource into account when setting up a future connection. In either case, this might cause long connection setup times and increased signaling overhead caused by unsuccessful and thus superfluous signaling messages.